add maxOccurs="unbounded" which will allow more than one recording container to search.

Yes, thank you for your opinion. In the last meeting, one of the judges raised the desire to support the search of multiple recording container。

add maxOccurs="unbounded" which will allow more than one recording container to search.

how client gets this local storage URI to search?

Yes, thank you for your opinion. the TargetImageURI is the result returned from SearchImageByNL.

cannot we use SearchImagebyImage Request with out getting result from SearchImageByNL? I feel SearchImagebyImage and SearchImageByNL are independent search sessions, i.e one is image based search and other is text based search.

@WANGXIAOMIN-HIK Yes I agree with @venki5685. I feel there shhould not be a dependence on either API!.

thank you for your opinion. @venki5685 @kieran242
We think about it carefully, SearchImagebyImage and SearchImageByNL are independent search sessions.
TargetImageURI can be a local URI or a remote URI.

FindImagebyImage name can be revisited.

Yes, thank you for your opinion. We change the FindImageByImage to SearchImageByImage, and FindImageByNL to SearchImageByNL.

Please pay attention to #603 5b48ba2, the other two records are bad commits (dff6a6f and 57a89d5).

SerachImagebyImage -> SearchImagebyImage

Thank you for your clear feedback. I have now fixed the issue.I appreciate your help.

Thank you very much for your advice. I have fixed the spelling error. I appreciate your help.

add a search parameter to accept external image from client in addition to NPL Target image URI. Either client can use NPLTargetImageURI or External Image from client for image search feature.

We Update the search functionality, add the TargetImageData parameter.

@WANGXIAOMIN-HIK please add an entry for "NPL" to this documents "Definitions" in section 3.1 to explain that it is "Natural Language Processing". It will add clarity in the document.

CosineSimularity is just one out of a set of common simularity measures.
I can imagine that ONVIF just defines an abstract simularity bewteen zero and one or a complex item supporting multiple similarity measures.

For the sake of simplicity I prefer the first approach as the second one would require a set of capabilities which ones a device supports.

yes,
Cosine similarity is just one of the most commonly used similarity measures in vector space. In actual image retrieval/similarity assessment, multiple distance measures, matching based on local features, perceptual similarity, as well as learned metrics or hash/quantization indexing are also used.
Could we consider changing the field back to 'simularity', but in the comments, we can note that we are currently using the cosine vector method? @dstafx

Ok for me since this is a big and important topic that we likely need to come back to on a more general level. But to explain a bit more:

My general concern (and the industry challenge) is that if we are too generic it will not be useful across vendors as the implementation scores would not be compareable. The message to the client if it is a generic number is likely that every enpoint where this interface is offered may have different implementations so the similarity is not comparable between different endpoints. So when searching some devices or vendors may consistently report higher similarities thereby potentially hiding relevant results. By stating that the similarity is only for sorting search results from a single endpoint we can avoid this.

Thank you very much for your detailed explanation. After careful consideration, I still think it should be defined as similarity, as we cannot restrict the vendors' implementation algorithms.

However, regarding the issue you mentioned about cross-device and cross-vendor search, we can add a note stating that this similarity is only guaranteed to be effective for ranking within the same search result returned by the same endpoint, and it does not guarantee that similarity can be compared across different vendors, devices, or endpoints.

As for the cross-device search issue, we can discuss it in our next meeting. This would require imposing constraints on the hardware vendors' implementation mechanisms, such as ensuring that devices support the same algorithm scheduling to guarantee consistency in device detection mechanisms.